System for processing data using different processing channels based on source error probability

ABSTRACT

Systems, computer program products, and methods are described herein for routing data processing among different processing channels based on source-error probabilities. The present invention is configured to receive a data processing job comprising at least one data processing item; determine a first source of the at least one data processing item; determine a source error probability associated with the first source; and based on the determined source error probability, route the data processing item for data processing to an automated data processing network or a manual data processing network.

BACKGROUND

Entities typically receive large volumes of documents from vendors,customers, or employees on any given day. Each document, especially ifit is a financial instrument, is often reconciled with a batch ofsimilar financial instruments for further processing. A financialinstrument processing system may include many nodes or modules that areused to process a financial instrument including determining whether theinstrument is an exception, which may mean the financial instrumentincludes an ambiguity or otherwise contains a problem needingremediation action.

BRIEF SUMMARY

Embodiments of the present invention address the above needs and/orachieve other advantages by providing apparatuses (e.g., a system,computer program product and/or other devices) and methods formonitoring module or node usage in a data processing system.

In one aspect, a data processing system for routing data processingamong different processing channels based on source-error probabilitiesis presented. The data processing system comprising: a memory devicewith computer-readable program code stored thereon; a communicationdevice; a processing device operatively coupled to the memory device andthe communication device, wherein the processing device is configured toexecute the computer-readable program code to: receive a data processingjob comprising at least one data processing item; determine a firstsource of the at least one data processing item; determine a sourceerror probability associated with the first source; and based on thedetermined source error probability, route the data processing item fordata processing to an automated data processing network or a manual dataprocessing network.

In some embodiments, the processing device is further configured toexecute computer-readable code to: determine a second source ofinformation associated with the data processing item; determine a sourceerror probability associated with the second source; and based on thedetermined source error probabilities associated with both the firstsource and/or the second source, route or re-route the data processingitem for data processing.

In some embodiments, the processing device is further configured toexecute computer-readable code to: determine a third source ofinformation associated with the data processing item; determine a sourceerror probability associated with the third source; and based on thedetermined source error probabilities associated with the first source,the second source and/or the third source, route or re-route the dataprocessing item for data processing.

In some embodiments, the processing device is further configured toexecute computer-readable code to: route the data processing item to anautomated data processing network; and in response, determine the secondsource.

In some embodiments, the processing device is further configured toexecute computer-readable code to: based on the source error probabilityof the second source, re-route the data processing item to a manual dataprocessing network.

In some embodiments, the processing device is further configured toexecute computer-readable code to: based on the source error probabilityof the second source, re-route the data processing item to a secondautomatic data processing network; determine a third source of the atleast one data processing item; determine a source error probabilityassociated with the third source; and based on the determined sourceerror probabilities associated with the third source, re-route orre-route the data processing item to a manual data processing network.

In some embodiments, the processing device is further configured toexecute computer-readable code to: combine the source errorprobabilities associated with each of the first source, second sourceand third source; compare the combined source error probabilities to apredetermined threshold; and in response, route the data processingitem.

In some embodiments, the second source of information comprisesfinancial institution backend information and the third source ofinformation comprises customer information.

In some embodiments, the processing device is further configured toexecute computer-readable code to: determine a type associated with thefirst source; based on the type of the first source, determine a levelof scrutiny for considering data processing items sourced from the firstsource; and based on the determined level of scrutiny, route the dataprocessing item.

In some embodiments, the processing device is further configured toexecute computer-readable code to: determine at least one second sourceof information associated with the data processing item; compareinformation from the first source with the information from the secondsource; and in response, adjust the level of scrutiny lower if theinformation is the same and higher if the information is different.

In some embodiments, the at least one second source of informationcomprises a financial institution backend system and/or a customerinformation system.

In another aspect, a computer program product for routing dataprocessing among different processing channels based on source-errorprobabilities is presented. The computer program product comprising atleast one non-transitory computer-readable medium havingcomputer-readable program code portions embodied therein, thecomputer-readable program code portions comprising: an executableportion configured for receiving a data processing job comprising atleast one data processing item; an executable portion configured fordetermining a first source of the at least one data processing item; anexecutable portion configured for determining a source error probabilityassociated with the first source; and based on the determined sourceerror probability, an executable portion configured for routing the dataprocessing item for data processing to an automated data processingnetwork or a manual data processing network.

In yet another aspect, a computer-implemented method for routing dataprocessing among different processing channels based on source-errorprobabilities is presented. The method comprising: receiving, using acomputing device processor, a data processing job comprising at leastone data processing item; determining, using a computing deviceprocessor, a first source of the at least one data processing item;determining, using a computing device processor, a source errorprobability associated with the first source; and based on thedetermined source error probability, routing, using a computing deviceprocessor, the data processing item for data processing to an automateddata processing network or a manual data processing network

The features, functions, and advantages that have been discussed may beachieved independently in various embodiments of the present inventionor may be combined with yet other embodiments, further details of whichcan be seen with reference to the following description and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described embodiments of the invention in general terms,reference will now be made to the accompanying drawings, wherein:

FIG. 1 provides a dynamic resource management for document exceptionprocessing system environment, in accordance with one embodiment of thepresent invention;

FIG. 2A provides a high level process flow illustrating documentexception identification and processing, in accordance with oneembodiment of the present invention;

FIG. 2B provides a high level process flow illustrating general datalifting for document exception processing, in accordance with oneembodiment of the present invention;

FIG. 3 provides a high level process flow illustrating identifying andextracting data from payment instruments, in accordance with oneembodiment of the present invention;

FIG. 4 illustrates an exemplary image of a financial record, inaccordance with one embodiment of the present invention;

FIG. 5 provides an exemplary template of a financial record, inaccordance with one embodiment of the present invention;

FIG. 6 provides a process flow illustrating exception processing, inaccordance with one embodiment of the present invention;

FIG. 7 provides a process flow for routing data processing amongdifferent processing channels based on source-error probabilities, inaccordance with an embodiment of an invention; and

FIG. 8 provides a process flow for routing data processing amongdifferent data processing channels based on secondary and tertiaryinformation sources, in accordance with embodiments of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Embodiments of the present invention will now be described more fullyhereinafter with reference to the accompanying drawings, in which some,but not all, embodiments of the invention are shown. Indeed, theinvention may be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein; rather, theseembodiments are provided so that this disclosure will satisfy applicablelegal requirements. Like numbers refer to elements throughout. Wherepossible, any terms expressed in the singular form herein are meant toalso include the plural form and vice versa, unless explicitly statedotherwise. As used herein, a “document,” “financial document,”“financial record,” or “payment instrument” may also refer to a myriadof financial documents, including but not limited to a lease document, amortgage document, a deposit slip, a payment coupon, a receipt, generalledger tickets, or the like. In some embodiments, “document”, “financialrecord” may exist as a physical item printed on paper or other medium.In other embodiments, the check may exist electronically. Furthermore,“document,” “financial document,” “financial record,” or “paymentinstrument” may also refer to records associated with government data,legal data, identification data, and the like. Although the disclosureis directed to financial records, it will be understood thatnon-financial records such as social communications, advertising, blogs,opinion writing, and the like may also be applicable to the disclosurepresented herein. In cases were non-financial records are use, it willbe understood that personal information, such personal identifyinginformation, account numbers, and the like, can be removed from thedocuments before they are released. For example, if a coupon or productreview is to be used in advertising, personal information associatedwith such records will be removed before the advertising is presented tothe public. The data of the financial records or non-financial recordsmay be provided in a wide variety formats including, paper records,electronic or digital records, video records, audio records, and/orcombinations thereof. In some embodiments, the “document” or “financialrecord” may be referred to in examples as a check or the like.Furthermore, the term “image lift data” or “data lift” may refer to theprocess of lifting one or more areas/elements of a document and storingthose areas as metadata without storing the entire document as an imagefile.

Some portions of this disclosure are written in terms of a financialinstitution's unique position with respect document processing andretrieving. As such, a financial institution may be able to utilize itsunique position to receive, store, process, and retrieve images ofdocuments, such as those of a financial nature.

As presented herein, embodiments that detect and extract specific datafrom images and that analyze, process, and distribute extracted metadataare provided.

FIG. 1 illustrates a dynamic resource management for document exceptionprocessing system environment 200, in accordance with some embodimentsof the invention. The environment 200 includes a check deposit device211 associated or used with authorization of a user 210 (e.g., anaccount holder, a mobile application user, an image owner, a bankcustomer, and the like), a third party system 260, and a financialinstitution system 240. In some embodiments, the third party system 260corresponds to a third party financial institution. The environment 200further includes one or more third party systems 292 (e.g., a partner,agent, or contractor associated with a financial institution), one ormore other financial institution systems 294 (e.g., a credit bureau,third party banks, and so forth), and one or more external systems 296.

The systems and devices communicate with one another over the network230 and perform one or more of the various steps and/or methodsaccording to embodiments of the disclosure discussed herein. The network230 may include a local area network (LAN), a wide area network (WAN),and/or a global area network (GAN). The network 230 may provide forwireline, wireless, or a combination of wireline and wirelesscommunication between devices in the network. In one embodiment, thenetwork 230 includes the Internet.

The check deposit device 211, the third party system 260, and thefinancial institution system 240 each includes a computer system,server, multiple computer systems and/or servers or the like. Thefinancial institution system 240, in the embodiments shown has acommunication device 242 communicably coupled with a processing device244, which is also communicably coupled with a memory device 246. Theprocessing device 244 is configured to control the communication device242 such that the financial institution system 240 communicates acrossthe network 230 with one or more other systems. The processing device244 is also configured to access the memory device 246 in order to readthe computer readable instructions 248, which in some embodimentsincludes a one or more OCR engine applications 250 and a client keyingapplication 251. The memory device 246 also includes a datastore 254 ordatabase for storing pieces of data that can be accessed by theprocessing device 244. In some embodiments, the datastore 254 includes acheck data repository.

As used herein, a “processing device,” generally refers to a device orcombination of devices having circuitry used for implementing thecommunication and/or logic functions of a particular system. Forexample, a processing device may include a digital signal processordevice, a microprocessor device, and various analog-to-digitalconverters, digital-to-analog converters, and other support circuitsand/or combinations of the foregoing. Control and signal processingfunctions of the system are allocated between these processing devicesaccording to their respective capabilities. The processing device 214,244, or 264 may further include functionality to operate one or moresoftware programs based on computer-executable program code thereof,which may be stored in a memory. As the phrase is used herein, aprocessing device 214, 244, or 264 may be “configured to” perform acertain function in a variety of ways, including, for example, by havingone or more general-purpose circuits perform the function by executingparticular computer-executable program code embodied incomputer-readable medium, and/or by having one or moreapplication-specific circuits perform the function.

Furthermore, as used herein, a “memory device” generally refers to adevice or combination of devices that store one or more forms ofcomputer-readable media and/or computer-executable programcode/instructions. Computer-readable media is defined in greater detailbelow. For example, in one embodiment, the memory device 246 includesany computer memory that provides an actual or virtual space totemporarily or permanently store data and/or commands provided to theprocessing device 244 when it carries out its functions describedherein.

The check deposit device 211 includes a communication device 212 and animage capture device 215 (e.g., a camera) communicably coupled with aprocessing device 214, which is also communicably coupled with a memorydevice 216. The processing device 214 is configured to control thecommunication device 212 such that the check deposit device 211communicates across the network 230 with one or more other systems. Theprocessing device 214 is also configured to access the memory device 216in order to read the computer readable instructions 218, which in someembodiments includes a capture application 220 and an online bankingapplication 221. The memory device 216 also includes a datastore 222 ordatabase for storing pieces of data that can be accessed by theprocessing device 214. The check deposit device 211 may be a mobiledevice of the user 210, a bank teller device, a third party device, anautomated teller machine, a video teller machine, or another devicecapable of capturing a check image.

The third party system 260 includes a communication device 262 and animage capture device (not shown) communicably coupled with a processingdevice 264, which is also communicably coupled with a memory device 266.The processing device 264 is configured to control the communicationdevice 262 such that the third party system 260 communicates across thenetwork 230 with one or more other systems. The processing device 264 isalso configured to access the memory device 266 in order to read thecomputer readable instructions 268, which in some embodiments includes atransaction application 270. The memory device 266 also includes adatastore 272 or database for storing pieces of data that can beaccessed by the processing device 264.

In some embodiments, the capture application 220, the online bankingapplication 221, and the transaction application 270 interact with theOCR engines 250 to receive or provide financial record images and data,detect and extract financial record data from financial record images,analyze financial record data, and implement business strategies,transactions, and processes. The OCR engines 250 and the client keyingapplication 251 may be a suite of applications for conducting OCR.

In some embodiments, the capture application 220, the online bankingapplication 221, and the transaction application 270 interact with theOCR engines 250 to utilize the extracted metadata to determine decisionsfor exception processing. In this way, the system may systematicallyresolve exceptions. The exceptions may include one or moreirregularities such as bad micro line reads, outdated check stock, ormisrepresentative checks that may result in a failure to match the checkto an associated account for processing. As such, the system mayidentify the exception and code it for exception processing.Furthermore, the system may utilize the metadata to match the check to aparticular account automatically.

In some embodiments, the capture application 220, the online bankingapplication 221, and the transaction application 270 interact with theOCR engines 250 to utilize the extracted metadata for automated paymentstops when detecting a suspect document or time during processing. Inthis way, the system may identify suspect items within the extractedmetadata. The document or check processing may be stopped because ofthis identification. In some embodiments, the suspect items may bedetected utilizing OCR based on data received from a customer externalto the document in comparison to the document. In some embodiments, thesuspect items may be detected utilizing OCR based on data associatedwith the account in comparison to the document.

In some embodiments, the capture application 220, the online bankingapplication 221, and the transaction application 270 interact with theOCR engines 250 to utilize the extracted metadata for automateddecisions for detecting and/or eliminating duplicate check processing.Duplicate checks may be detected and/or eliminated based on metadatamatching. In this way, data may be lifted off of a document as metadataand compare the data to other documents utilizing the metadata form. Assuch, the system does not have to overlay images in order to detectduplicate documents.

The applications 220, 221, 250, 251, and 270 are for instructing theprocessing devices 214, 244 and 264 to perform various steps of themethods discussed herein, and/or other steps and/or similar steps. Invarious embodiments, one or more of the applications 220, 221, 250, 251,and 270 are included in the computer readable instructions stored in amemory device of one or more systems or devices other than the systems260 and 240 and the check deposit device 211. For example, in someembodiments, the application 220 is stored and configured for beingaccessed by a processing device of one or more third party systems 292connected to the network 230. In various embodiments, the applications220, 221, 250, 251, and 270 stored and executed by differentsystems/devices are different. In some embodiments, the applications220, 221, 250, 251, and 270 stored and executed by different systems maybe similar and may be configured to communicate with one another, and insome embodiments, the applications 220, 221, 250, 251, and 270 may beconsidered to be working together as a singular application despitebeing stored and executed on different systems.

In various embodiments, one of the systems discussed above, such as thefinancial institution system 240, is more than one system and thevarious components of the system are not collocated, and in variousembodiments, there are multiple components performing the functionsindicated herein as a single device. For example, in one embodiment,multiple processing devices perform the functions of the processingdevice 244 of the financial institution system 240 described herein. Invarious embodiments, the financial institution system 240 includes oneor more of the external systems 296 and/or any other system or componentused in conjunction with or to perform any of the method steps discussedherein. For example, the financial institution system 240 may include afinancial institution system, a credit agency system, and the like.

In various embodiments, the financial institution system 240, the thirdparty system 260, and the check deposit device 211 and/or other systemsmay perform all or part of a one or more method steps discussed aboveand/or other method steps in association with the method steps discussedabove. Furthermore, some or all the systems/devices discussed here, inassociation with other systems or without association with othersystems, in association with steps being performed manually or withoutsteps being performed manually, may perform one or more of the steps ofmethod 300, the other methods discussed below, or other methods,processes or steps discussed herein or not discussed herein.

Referring now to FIG. 2A, FIG. 2A presents provides a high level processflow illustrating document exception identification and processing 150,in accordance with some embodiments of the invention. As illustrated inblock 120, the method comprises receiving an image of a check. The imagereceived may be one or more of a check, other document, paymentinstrument, and/or financial record. In some embodiments, the image ofthe check may be received by a specialized apparatus associated with thefinancial institution (e.g. a computer system) via a communicable linkto a user's mobile device, a camera, an Automated Teller Machine (ATM)at one of the entity's facilities, a second apparatus at a teller'sstation, another financial institution, or the like. In otherembodiments, the apparatus may be specially configured to capture theimage of the check for storage and exception processing.

As illustrated in block 122, the system may then lift data off of thecheck (document, payment instrument, or financial record) using opticalcharacter recognition (OCR). The OCR processes enables the system toconvert text and other symbols in the check images to other formats suchas text files and/or metadata, which can then be used and incorporatedinto a variety of applications, documents, and processes. In someembodiments, OCR based algorithms used in the OCR processes incorporatepattern matching techniques. For example, each character in an imagedword, phrase, code, or string of alphanumeric text can be evaluated on apixel-by-pixel basis and matched to a stored character. Variousalgorithms may be repeatedly applied to determine the best match betweenthe image and stored characters.

After the successful retrieval or capture of the image of the check, theapparatus may process the check as illustrated in block 126. Theapparatus may capture individual pieces of check information from theimage of the check in metadata form. In some embodiments, the checkinformation may be text. In other embodiments, the check information maybe an image processed into a compatible data format.

As illustrated in block 124, the method comprises storing checkinformation. After the image of the check is processed, the apparatusmay store the lifted and collected check information in a compatibledata format. In some embodiments, the check information may be stored asmetadata. As such, individual elements of the check information may bestored separately, and may be associated with each other via metadata.In some embodiments, the individual pieces of check information may bestored together. In some embodiments, the apparatus may additionallystore the original image of the check immediately after the image of thecheck is received.

As illustrated in block 128, the process 150 continues by identifyingexceptions in the document processing. Exceptions may be one or more ofirregularities such as bad micro line reads, outdated document stock,misrepresented items, or the like that result in a failure to match thedocument to an account. In some embodiments, the process may also detectduplicate documents. In yet other embodiments, the system may identifypayment stops for specific documents.

Next, as illustrated in block 130, the process 150 continues to batchexceptions for processing and quieting them for resource review. In someembodiments, the system may first provide automated decisions forexception processing utilizing the lifted data. In this way, the systemmay utilize the data lifted from the document in order to rectify theexception identified in block 128. In this way, the system may be ableto rectify the exception without having to have an individual manuallyoverride the exception and identify the account associated with thedocument with the exception. In some embodiments, a confidence of theautomated decisions for exception processing may be generated. Upon alow confidence or that below a threshold such as 100%, 95%, or 90%, thesystem may queue the exception to a work flow node for paymentinstrument processing by a resource. The queue of the resource may bedetermined based on dynamic resource management described below.

Referring now to FIG. 2B, FIG. 2B presents provides a high level processflow illustrating general data lifting for document exception processing160, in accordance with some embodiments of the invention. Asillustrated in block 132, the process 160 starts by identifying theexceptions in financial document or payment instrument processing. Onceidentified, the documents associated with each of the one or moreexceptions may be categorized as either debit or credit documents, asillustrated in block 134. In this way, the system may identify anexception and identify the type of document that the exception wasidentified from.

Next, as illustrate in decision block 136, the system may identify ifthe document is a check or if it is another financial document orpayment instrument for processing. If the financial document is a checkin decision block 136, the system will identify if the check is apre-authorized draft check, as illustrated in block 138. In someembodiments, pre-authorized draft checks are made via online purchasesthat ask a user for his/her check number and routing number. Thepre-authorized draft check is subsequently converted to paper form andsubmitted to the financial institution for processing. Thesepre-authorized draft checks may undergo a higher level of processingscrutiny to ensure authenticity, if necessary.

Next, as illustrated in block 140, automated decisions are created forthe financial documents with exceptions based on lifted data and thetype of exception identified. Once automated decisions are made, thesystem identifies a confidence of the automated decision.

In some embodiments, the system may send the exceptions for processingto a work flow node for exception processing by a resource, asillustrated in block 150. In yet other embodiments, the resource mayreceive an already automatically processed exception to confirm thecorrect processing.

Referring now to FIG. 3, FIG. 3 provides a high level process flowillustrating identifying and extracting data from payment instruments100, in accordance with some embodiments in the invention. One or moredevices, such as the one or more systems and/or one or more computingdevices and/or servers of FIG. 3 can be configured to perform one ormore steps of the process 100 or other processes described below. Insome embodiments, the one or more devices performing the steps areassociated with a financial institution. In other embodiments, the oneor more devices performing the steps are associated with a merchant,business, partner, third party, credit agency, account holder, and/oruser.

As illustrated at block 102, one or more check images are received. Thecheck images comprise the front portion of a check, the back portion ofa check, or any other portions of a check. In cases where there areseveral checks piled into a stack, the multiple check images mayinclude, for example, at least a portion of each of the four sides ofthe check stack. In this way, any text, numbers, or other data providedon any side of the check stack may also be used in implementing theprocess 100. In some embodiments the system may receive financialdocuments, payment instruments, checks, or the likes.

In some embodiments, each of the check images comprises financial recorddata. The financial record data includes dates financial records areissued, terms of the financial record, time period that the financialrecord is in effect, identification of parties associated with thefinancial record, payee information, payor information, obligations ofparties to a contract, purchase amount, loan amount, consideration for acontract, representations and warranties, product return policies,product descriptions, check numbers, document identifiers, accountnumbers, merchant codes, file identifiers, source identifiers, and thelike.

Although check images are illustrated in FIG. 4 and FIG. 5, it will beunderstood that any type of financial record image may be received.Exemplary check images include PDF files, scanned documents, digitalphotographs, and the like. At least a portion of each of the checkimages, in some embodiments, is received from a financial institution, amerchant, a signatory of the financial record (e.g., the entity havingauthority to endorse or issue a financial record), and/or a party to afinancial record. In other embodiments, the check images are receivedfrom image owners, account holders, agents of account holders, familymembers of account holders, financial institution customers, payors,payees, third parties, and the like. In some embodiments, the source ofat least one of the checks includes an authorized source such as anaccount holder or a third party financial institution. In otherembodiments, the source of at least one of the checks includes anunauthorized source such as an entity that intentionally orunintentionally deposits or provides a check image to the system ofprocess 100.

In some exemplary embodiments, a customer or other entity takes apicture of a check at a point of sales or an automated teller machine(ATM) and communicates the resulting check image to a point of salesdevice or ATM via wireless technologies, near field communication (NFC),radio frequency identification (RFID), and other technologies. In otherexamples, the customer uploads or otherwise sends the check image to thesystem of process 100 via email, short messaging service (SMS) text, aweb portal, online account, mobile applications, and the like. Forexample, the customer may upload a check image to deposit funds into anaccount or pay a bill via a mobile banking application using a capturedevice. The capture device can include any type or number of devices forcapturing images or converting a check to any type of electronic formatsuch as a camera, personal computer, laptop, notebook, scanner, mobiledevice, and/or other device.

As illustrated at block 104, optical character recognition (OCR)processes are applied to at least a portion of the check images. Atleast one OCR process may be applied to each of the check images or someof the check images. The OCR processes enables the system to converttext and other symbols in the check images to other formats such as textfiles and/or metadata, which can then be used and incorporated into avariety of applications, documents, and processes. In some embodiments,OCR based algorithms used in the OCR processes incorporate patternmatching techniques. For example, each character in an imaged word,phrase, code, or string of alphanumeric text can be evaluated on apixel-by-pixel basis and matched to a stored character. Variousalgorithms may be repeatedly applied to determine the best match betweenthe image and stored characters.

As illustrated in block 106, the check data may be identified based onthe applied OCR processing. In some embodiments, the OCR processincludes location fields for determining the position of data on thecheck image. Based on the position of the data, the system can identifythe type of data in the location fields to aid in character recognition.For example, an OCR engine may determine that text identified in theupper right portion of a check image corresponds to a check number. Thelocation fields can be defined using any number of techniques. In someembodiments, the location fields are defined using heuristics. Theheuristics may be embodied in rules that are applied by the system fordetermining approximate location.

In other embodiments, the system executing process flow 100 defines thelocation fields by separating the portions and/or elements of the imageof the check into quadrants. As referred to herein, the term quadrant isused broadly to describe the process of differentiating elements of acheck image by separating portions and/or elements of the image of thecheck into sectors in order to define the location fields. These sectorsmay be identified using a two-dimensional coordinate system or any othersystem that can be used for determining the location of the sectors. Inmany instances, each sector will be rectangular in shape. In someembodiments, the system identifies each portion of the image of thecheck using a plurality of quadrants. In such an embodiment, the systemmay further analyze each quadrant using the OCR algorithms in order todetermine whether each quadrant has valuable or useful information.Generally, valuable or useful information may relate to any data orinformation that may be used for processing and/or settlement of thecheck, used for identifying the check, and the like. Once the systemdetermines the quadrants of the image of the check having valuableand/or useful information, the system can extract the identifiedquadrants together with the information from the image of the check forstorage. The quadrants may be extracted as metadata, text, or coderepresenting the contents of the quadrant. In some embodiments, thequadrants of the image of the check that are not identified as havingvaluable and/or useful information are not extracted from the image.

In additional embodiments, the system uses a grid system to identifynon-data and data elements of a check image. The grid system may besimilar to the quadrant system. Using the grid system, the systemidentifies the position of each grid element using a coordinate system(e.g., x and y coordinates or x, y, and z coordinate system or the like)or similar system for identifying the spatial location of a grid elementon a check. In practice, the spatial location of a grid element may beappended to or some manner related to grid elements with check data. Forexample, using the grid, the system may identify which grid elements ofthe grid contain data elements, such as check amount and payee name, andeither at the time of image capture or extraction of the check imagewithin the grid, the system can tag the grid element having the checkdata element with the grid element's spatial location. In someembodiments, the grid system and/or quadrant system is based on stockcheck templates obtained from check manufacturers or merchants.

In alternative or additional embodiments, the OCR process includespredefined fields to identify data. The predefined field includes one ormore characters, words, or phrases that indicate a type of data. In suchembodiments, the system of process 100 extracts all the data presentedin the check image regardless of the location of the data and uses thepredefined fields to aid in character recognition. For example, apredefined field containing the phrase “Pay to the order of” may be usedto determine that data following the predefined field relates to payeeinformation.

In addition to OCR processes, the system of process 100 can use othertechniques such as image overlay to locate, identify, and extract datafrom the check images. In other embodiments, the system uses themagnetic ink character recognition (MICR) to determine the position ofnon-data (e.g., white space) and data elements on a check image. Forexample, the MICR of a check may indicate to the system that thereceived or captured check image is a business check with certaindimensions and also, detailing the location of data elements, such asthe check amount box or Payee line. In such an instance, once thepositions of this information is made available to the system, thesystem will know to capture any data elements to the right or to theleft of the identified locations or include the identified data elementin the capture. This system may choose to capture the data elements of acheck in any manner using the information determined from the MICRnumber of the check.

As illustrated at block 108, unrecognized data from the check images isdetected. In some embodiments, the unrecognized data includescharacters, text, shading, or any other data not identified by the OCRprocesses. In such embodiments, the unrecognized data is detectedfollowing implementation of at least one of the OCR processes. In otherembodiments, the unrecognized data is detected prior to application ofthe OCR processes. For example, the unrecognized data may be removed andseparated from the check images or otherwise not subjected to the OCRprocesses. In one exemplary situation, the system may determine thathandwritten portions of a check image should not undergo OCR processingdue to the difficulty in identifying such handwritten portions.Exemplary unrecognized data includes handwritten text, blurred text,faded text, misaligned text, misspelled data, any data not recognized bythe OCR processes or other data recognition techniques, and the like. Inother cases, at least a portion of some or all of the check images mayundergo pre-processing to enhance or correct the unrecognized data. Forexample, if the text of a check image is misaligned or blurry, thesystem may correct that portion of the check image before applying theOCR processes to increase the probability of successful text recognitionin the OCR processes or other image processes.

As illustrated at block 110, in some embodiments the system will haveone or more resources review the unrecognized data. As such, there maybe one or more individuals reviewing the unrecognized data instead ofmechanically reviewing the data. As illustrated in block 110, the systemmay receive input from the resource that provides informationidentifying the unrecognized data. As such, a resource may be providedwith the portions of a check image corresponding to the unrecognizeddata. The resource can view the unrecognized data to translate theunrecognized data into text and input the translation into a check datarepository. In this way, the system “learns” to recognize previouslyunrecognized data identified by the resource, such that when the systemreviews the same or similar unrecognized data in the future, such datacan be easily identified by reference to the check data repository.

In other embodiments, the system may present an online banking customerwith the unrecognized data to solicit input directly from the customer.For example, the customer may be presented with operator-defined termsof previously unrecognized data to verify if such terms are correct. Thesystem may solicit corrective input from the customer via an onlinebanking portal, a mobile banking application, and the like. If anoperator or resource initially determines that the handwriting on thememo line reads “house flaps,” the customer may subsequently correct theoperator's definition and update the check data repository so that thehandwritten portion correctly corresponds to “mouse traps.” In someembodiments, the customer's input is stored in a customer inputrepository, which is linked to the check data repository associated withthe OCR processes. For example, the system can create a file pathlinking the customer input repository with the check data repository toautomatically update the check data repository with the customer input.In other embodiments, the check data repository and/or customer inputrepository includes stored customer data or account data. Storedcustomer signatures, for example, may be included in the check datarepository and/or customer input repository.

As illustrated at block 111, the process 100 continues by determining,based on the confidence level of the resource and initial unrecognizeddata, determine if a secondary check of the unrecognized data isnecessary. As such, based on a confidence level determined from theresource, the system may require additional checking to confirm theaccuracy of the identification of the unrecognized data from the check.

Finally, as illustrated in block 112, business strategies andtransactions are processed based on at least one of the check data andthe inputted information. Data extracted from the check images using theprocess 100 may be used to automate or enhance various processes such asremediating exception processes, replacing check images with check datain online statements, enforcing requirements regarding third party checkdeposits, facilitating check to automated clearing house transactionconversion, cross selling products, and so forth.

FIG. 4 provides an illustration of an exemplary image of a financialrecord 300, in accordance with one embodiment of the present invention.The financial record illustrated in FIG. 4 is a check. However, one willappreciate that any financial record, financial document, paymentinstrument, or the like may be provided.

The image of check 300 may comprise an image of the entire check, athumbnail version of the image of the check, individual pieces of checkinformation, all or some portion of the front of the check, all or someportion of the back of the check, or the like. Check 300 comprises checkinformation, wherein the check information comprises contact information305, the payee 310, the memo description 315, the account number androuting number 320 associated with the appropriate user or customeraccount, the date 325, the check number 330, the amount of the check335, the signature 340, or the like. In some embodiments, the checkinformation may comprise text. In other embodiments, the checkinformation may comprise an image. A capture device may capture an imageof the check 300 and transmit the image to a system of a financialinstitution via a network. The system may collect the check informationfrom the image of the check 300 and store the check information in adatastore as metadata. In some embodiments, the pieces of checkinformation may be stored in the datastore individually. In otherembodiments, multiple pieces of check information may be stored in thedatastore together.

FIG. 5 illustrates an exemplary template of a financial record 400, inaccordance with one embodiment of the present invention. Again, thefinancial record illustrated in FIG. 5 is a check. However, one willappreciate that any financial record, financial document, paymentinstruments, or the like may be provided.

In the illustrated embodiment, the check template 400 corresponds to theentire front portion of a check, but it will be understood that thecheck template 400 may also correspond to individual pieces of checkinformation, portions of a check, or the like. The check template, insome embodiments, includes the format of certain types of checksassociated with a bank, a merchant, an account holder, types of checks,style of checks, check manufacturer, and so forth. By using the checktemplate, the system may “learn” to map the key attributes of the checkfor faster and more accurate processing. In some embodiments, financialrecords are categorized by template. The check template 400 is only anexemplary template for a financial record, and other check templates orother financial record templates may be utilized to categorize checks orother financial records. The check template 400 can be used in the OCRprocesses, image overlay techniques, and the like.

The check template 400 comprises check information, wherein the checkinformation includes, for example, a contact information field 405, apayee line field 410, a memo description field 415, an account numberand routing number field 420 associated with the appropriate user orcustomer account, a date line field 425, a check number field 430, anamount box field 435, a signature line field 440, or the like.

FIG. 6 illustrates a process flow for exception processing 500, inaccordance with one embodiment of the present invention. As illustratedin block 502, the process 500 is initiated when financial documents orpayment instruments, such as checks, are received. The receivedfinancial document may be in various forms, such as in an image format.Processing of the document may proceed wherein the data from thedocument may be collected and lifted from the document as metadata. Thismetadata is lifted from the document utilizing optical characterrecognition (OCR). The OCR processes enables the system to convert textand other symbols in the document image to metadata, which can then beused and incorporated into exception processing. In some embodiments,OCR based algorithms used in the OCR processes incorporate patternmatching techniques. For example, each character in an imaged word,phrase, code, or string of alphanumeric text can be evaluated on apixel-by-pixel basis and matched to a stored character. Variousalgorithms may be repeatedly applied to determine the best match betweenthe image and stored characters.

Once the metadata is lifted from the document as illustrated in block502, the process 500 continues to compile and store the metadataassociated with the received financial documents, as illustrated inblock 504. As such, after the image of the document, such as a check, isprocessed, the system may compile and store the lifted and collectedcheck information as metadata. As such, individual elements of the checkinformation may be stored separately, together, or the like. In thisway, the system stores the type of document, the appearance of thedocument, the information on the document, such as numbers, accounts,dates, names, addresses, payee, payor, routing numbers, amounts,document backgrounds, or the like as metadata.

In some embodiments, the stored data may be structural metadata. Assuch, the data may be about the design and specification of thestructure of the data. In other embodiments, the data may be descriptivemetadata. As such, the data may be data describing in detail the contentof the financial record or document. In some embodiments, the metadataas described herein may take the form of structural, descriptive and/ora combination thereof.

Next, as illustrated in decision block 506, the system monitors thereceived documents to identify exceptions in the document processing.Exceptions may be one or more of irregularities such as bad micro linereads, outdated document stock, misrepresented items, or the like thatresult in a failure to match the document to an account intended to beassociated with that document. If no exception is identified, then theprocess 500 terminates.

As illustrated in block 507 the process 500 continues to identify andcategorize any identified exceptions into financial documents associatedwith debits or financial documents associated with credits. Asillustrated in block 508 the process 500 continues to confirm theirregularity in the financial document that lead to the exceptionidentification in decision block 506. The irregularity that lead to theexception may be one or more of a bad micro line read, outdateddocuments (such as an outdated check or deposit statement), or a generalfailure of the document to match an existing financial account.

Next, as illustrated in block 510, the process 500 continues to utilizethe metadata associated with the received financial documents tosystematically search for exception resolutions. As such, providingautomated decisions for exception processing utilizing the liftedmetadata. As such, the metadata lifted from the financial documents maybe utilized to search the accounts or other records at the financialinstitution to determine the correct account or record associated withthe exception document. For example, the exception may include anoutdated check. In this way, one or more of the routing numbers, accountnumbers, or the like may be incorrectly stated on the check. The systemwill take the data on that outdated check and convert it to a metadataformat. Thus, the system will utilize the metadata format of the routingnumber or the like to search the financial institution records toidentify that that particular routing number was used for a batch ofchecks for User 1. As such, the system will identify the correct user,User 1 associated with the check that had an exception. Other examplesmay include one or more of bad micro line reads, document or checkformat issues, or the like.

As such, the system may utilize the metadata lifted from the document inorder to rectify the exception identified in decision block 506. In thisway, the system may be able to rectify the exception without having tohave an individual manually override the exception and identify theaccount associated with the document with the exception.

Next, as illustrated in block 512, the process 500 continues bydetermining a confidence associated with the systematic resolution forexception resolution. In this way, a confidence of the automatedresolution is determined. If the confidence is not satisfactory, such asnot being above a pre-determined threshold, the system may send theexception to a resource based on the confidence score not reaching apre-determined threshold, as illustrated in block 518. Next, asillustrated in block 520, the system pay place the resolved exceptioninto financial document processing after resolution and confirmationfrom the resource.

Referring back to block 512 of FIG. 6, if a confidence is generatedsignificantly high enough to reach the pre-determined threshold, thesystem continues and automatically and systematically corrects theexception based on the match based on the confident systematicresolution, as illustrated in block 514. In some embodiments, there maybe one or more threshold confidences related to the exception. As such,if a match has been made between the metadata and a financial accountand it is above a pre-determined confidence, then the system mayautomatically correct the exception. However, in some embodiments, thesystem may request manual acceptance of the correction of the exception.

Finally, as illustrated in block 516, the corrected financial documentmay be placed back into the financial document processing for continuedprocessing after the exception has been identified and corrected viasystematic searching financial institution data utilizing metadataextracted from the original financial document with an exception.

FIG. 7 illustrates a process flow for routing data processing amongdifferent processing channels based on source-error probabilities 700,in accordance with an embodiment of an invention. Automated checkprocessing is increasingly replacing manual check processing. Withautomatic text recognition, checks can be processed entirely by machine,improving the efficiency of banking. Automated processing is also acost-cutting tool for banks, and a convenient shortcut for customers whocan quickly deposit checks using a machine. However, automatedprocessing has its own set of disadvantages, the most important of whichis dealing with error probability associated with the automated process.Typically, most automated processes are implemented after cost profileanalysis which discusses pertinent issues associated with the automationprocess, including but not limited to, the costs, risks, rewards, and/orthe like. In the realm of financial institution network services, theautomation of check processing requires tedious analysis since checkprocessing errors may have serious repercussions. The present inventionprovides the functional benefit of using a variable confidence levelanalysis to determine a level of scrutiny associated with the processingof the check to determine whether a check can continue to be processedusing the automated process or requires manual intervention.

As shown in block 702, the process flow includes receiving a dataprocessing job including at least one processing item. Typically theprocessing item is associated with the financial institution, i.e. thefinancial document. In some embodiments, the processing item may be acheck. In this aspect, the processing item may be a physical papercheck, a scanned image of the check, a set of information extracted fromthe scanned image of the check, and/or the like. In some embodiments,the set of information extracted from the check image may include but isnot limited to a payee, a payor, a date, a memo line data, a paymentamount, a check number, and endorsement, a signature, and/or the like.Typically, the information extracted from the scanned image of the checkmay be used in processing the check, i.e., multiple funds have beentransferred from a payor's account and debited into a payee's account.

Next, as shown in block 704, the process flow includes determining afirst source of the data processing item. In one aspect, the firstsource associated with the data processing item may include but is notlimited to, a transaction terminal associated with the financialinstitution (e.g. an ATM), a point of sale terminal associated with themerchant, a transaction terminal associated with a third-party, a userdevice capable and authorized to accept the data processing item, and/orthe like. In embodiments where the first source is capable of scanningthe data processing item, the first source may also refer to informationassociated with a scanner involved in the capturing of the check image.In some embodiments, information associated with the scanner may includebut is not limited to, a type of scanner such as a high-speed checkscanner or single fee check scanner, a type of handwriting recognitionsoftware (e.g. magnetic ink character recognition) used to scan thecheck, a make and model of the check scanner, and/or the like. Infurther embodiments, the system may be configured to determine qualityof the check image including determining the resolution at which thecheck was scanned (e.g., 100 ppi, 200 ppi, 300 ppi, or the like), animage format associated with the check image (e.g., JPEG, TIFF, or thelike), an image type (e.g., black and white, grayscale, or the like), acommunication standard used in the electronic exchange of check images(e.g., X9.37), and/or the like.

For example, the first source may refer to both the ATM used by thecustomer to deposit the check and/or the information associated with thescanner installed within the ATM and configured to capture an image ofthe check for processing. In another example, the first source may referto the mobile device used by the customer to capture an image of thecheck, information associated with a software installed on the mobiledevice used to capture the image of the check, and informationassociated with the image capturing component associated with the mobiledevice used to capture the image of the check. In this way, the systemmay be configured to determine information associated with any hardwareand/or software component used in receiving the data processing item. Insome embodiments, the system may be configured to determine informationassociated with one or more communication channels involved in thetransmission and reception of the data processing item. In some otherembodiments, the system may be configured to determine informationassociated with any intermediate entity associated with the transmissionand reception of the data processing item.

Next, as shown in block 706, the process flow includes determining asource error probability associated with the first source. In thisregard, the system may be configured to determine an error marginassociated with the first source indicating a frequency associated withwhich the data processing item is mishandled. In some embodiments, theerror probability associated with the first source may indicate thereliability of the first source to capture information associated with adata processing item and transmit the captured information successfullyfor further processing. In some embodiments, the system may beconfigured to implement a level of scrutiny when processing the dataprocessing item. In this regard, the system may be configured todetermine the type associated with the first source and based on thetype of the first source determine a level of scrutiny for consideringdata processing items sourced from the first source and its type. Insome embodiments, the system may be configured to determine a level ofscrutiny for considering data processing items sourced from the firstsource regardless of the type. For example, the system may determinethat the mobile device of the customer used in capturing the informationfrom the check is an older version and not the version recommended bythe financial institution for the capture of check images. In response,the system may be configured to increase the level of scrutinyassociated with the processing of the check images captured by themobile device. In another example, the system may be configured todetermine that the scanner installed in an ATM at a particulargeographic location has been known to provide inconsistent check imagesin the past. In response, the system may be configured to increase thelevel of scrutiny associated with the processing of data processingitems captured by the scanner in that ATM. In yet another example, thesystem may be configured to determine that the check was deposited at aphysical facility associated with the financial institution. Inresponse, the system may be configured to decrease the level of scrutinyassociated with the data processing item.

Next, as shown in block 708, the process flow includes based thereon,routing the data processing item for data processing to an automateddata processing network or a manual data processing network. In someembodiments, the automated data processing network may include theprocess of generating an electronic file associated with the dataprocessing item and routing the data processing item via the financialinstitution network services to complete the transaction. For example,once the check is deposited, the financial institution may scan thecheck to capture an image and create a corresponding electronic file.The file is then sent to a clearinghouse that sorts checks to send tothe financial institutions against which the checks are drawn. Then,proprietary systems at the financial institution receive the data filefrom the check, match the data to the customer who initially wrote thecheck (payor), determine that the payor has sufficient funds in theirfinancial institution account, and then facilitate the transfer of fundsfrom the payor to the payee. In some other embodiments, the manual dataprocessing network involves the intervention of one or more financialinstitution employees to manually assess the check and/or the checkimage file to determine and/or confirm the set of information associatedwith the check.

FIG. 8 illustrates a process flow for routing data processing amongdifferent data processing channels based on secondary and tertiaryinformation sources 800, in accordance with embodiments of theinvention. As shown in block 802, the process flow includes determininga second resource of information associated with a data processing item.In this regard, the second source of information may include any backendinformation available to the financial institution regarding the dataprocessing item. For example, second source of information associatedwith a check may include, but is not limited to information associatedwith the payor, payee, an amount of funds, and/or the like. In oneaspect, information associated with the payor and/or the payee mayinclude, but is not associated with past transactions associated withpayor and/or the payee, financial behavior associated with the payorand/or the payee, a pattern associated with the past transactions and/orthe financial behavior associated with the payor and/or payee, and/orthe like. In another aspect, information associated with an amount offunds to be transferred includes determining whether the amount of fundsto be transferred is greater or lesser than a predetermined transactionamount limit.

Next, the process flow includes determining a source that areprobability associated with the second source, as shown in block 804. Inthis regard, the system may be configured to analyze the second sourceand the set of information associated with the check image to determinewhether the second source is within a tolerable and are probability. Forexample, the system may determine whether the information associatedwith the payee and the amount of funds to be transferred to the payeecorrespond to a predetermined pattern associated with past transactionsand/or financial behavior associated with the payor. The system may thendetermine whether the set of information associated with the check imageis within a tolerable that are probability associated with the secondsource. For example, if the transaction amount associated with the checkis $1000 and the payor and payee have been known to conduct transactionswith each other within a transaction amount range of $50-$5000, theerror probability associated with a second source is considered to bewithin tolerable limit. In another example, if the transaction amountassociated with the check is $50,000 and the payor and payee have beenknown to conduct transactions with each other within a transactionamount range of $50-$5000, the error probability associated with asecond source is considered to be outside tolerable limit.

Next, as shown in block 806, the process flow includes based on firstand/or first source error probability, route or re-route the dataprocessing item for data processing. In this regard, the data processingitem that was initially routed to the automated processing network basedon information associated with the first source may be re-routed to amanual data processing network based on at least the second source errorprobability and/or a combination of probabilities from both the firstsource and the second source. Similarly, data processing item initiallyrouted to the manual data processing network may then be rerouted to theautomated data processing network based on at least the second sourceerror probability and/or a combination of probabilities from both thefirst source and the second source.

Next, as shown in block 808, the process flow includes determining athird source of information associated with the data processing item. Inthis regard, the third source of information may include any externalcustomer information available to the financial institution. Forexample, the third source of information may include but is not limitedto social network information, geographic location information, customerprofile information, and/or the like. Accordingly, the system may beconfigured to determine a source error probability associated with thethird source, as shown in block 810. In response, the process flowincludes based on the first, second, and/or third source errorprobability, route or re-route the data processing item for dataprocessing. In this way, the system may combine better probabilitiesassociated with multiple sources to determine an ideal route for thedata processing item to be processed seamlessly.

In some embodiments, the level of scrutiny for considering the dataprocessing item may be adjustable based on at least combining theinformation associated with the first source with the informationassociated with the second and/or third sources. For example, if thetransaction amount associated with the check is $50,000 and the payorand payee have been known to conduct transactions with each other withthe transaction amount range of $50-$5000, the error probabilityassociated with the second source is considered to be outside tolerablelimit. In this case, the level of scrutiny associated with the check maybe high. However, the third source of information may indicate that thefinancial institution accounts associated with the payor and/or payeehave not been associated with misappropriate activity. In response, thelevel of scrutiny for considering the check may be lowered accordingly.

As will be appreciated by one of ordinary skill in the art, the presentinvention may be embodied as an apparatus (including, for example, asystem, a machine, a device, a computer program product, and/or thelike), as a method (including, for example, a business process, acomputer-implemented process, and/or the like), or as any combination ofthe foregoing. Accordingly, embodiments of the present invention maytake the form of an entirely software embodiment (including firmware,resident software, micro-code, or the like), an entirely hardwareembodiment, or an embodiment combining software and hardware aspectsthat may generally be referred to herein as a “system.” Furthermore,embodiments of the present invention may take the form of a computerprogram product that includes a computer-readable storage medium havingcomputer-executable program code portions stored therein. As usedherein, a processor may be “configured to” perform a certain function ina verity of ways, including, for example, by having one or moregeneral-purpose circuits perform the functions by executing one or morecomputer-executable program code portions embodied in acomputer-readable medium, and/or having one or more application-specificcircuits perform the function.

It will be understood that any suitable computer-readable medium may beutilized. The computer-readable medium may include, but is not limitedto, a non-transitory computer-readable medium, such as a tangibleelectronic, magnetic, optical, infrared, electromagnetic, and/orsemiconductor system, apparatus, and/or device. For example, in someembodiments, the non-transitory computer-readable medium includes atangible medium such as a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), a compact discread-only memory (CD-ROM), and/or some other tangible optical and/ormagnetic storage device. In other embodiments of the present invention,however, the computer-readable medium may be transitory, such as apropagation signal including computer-executable program code portionsembodied therein.

It will also be understood that one or more computer-executable programcode portions for carrying out operations of the present invention mayinclude object-oriented, scripted, and/or unscripted programminglanguages, such as, for example, Java, Perl, Smalltalk, C++, SAS, SQL,Python, Objective C, and/or the like. In some embodiments, the one ormore computer-executable program code portions for carrying outoperations of embodiments of the present invention are written inconventional procedural programming languages, such as the “C”programming languages and/or similar programming languages. The computerprogram code may alternatively or additionally be written in one or moremulti-paradigm programming languages, such as, for example, F#.

It will further be understood that some embodiments of the presentinvention are described herein with reference to flowchart illustrationsand/or block diagrams of systems, methods, and/or computer programproducts. It will be understood that each block included in theflowchart illustrations and/or block diagrams, and combinations ofblocks included in the flowchart illustrations and/or block diagrams,may be implemented by one or more computer-executable program codeportions. These one or more computer-executable program code portionsmay be provided to a processor of a general purpose computer, specialpurpose computer, and/or some other programmable data processingapparatus in order to produce a particular machine, such that the one ormore computer-executable program code portions, which execute via theprocessor of the computer and/or other programmable data processingapparatus, create mechanisms for implementing the steps and/or functionsrepresented by the flowchart(s) and/or block diagram block(s).

It will also be understood that the one or more computer-executableprogram code portions may be stored in a transitory or non-transitorycomputer-readable medium (e.g., a memory, or the like) that can direct acomputer and/or other programmable data processing apparatus to functionin a particular manner, such that the computer-executable program codeportions stored in the computer-readable medium produce an article ofmanufacture including instruction mechanisms which implement the stepsand/or functions specified in the flowchart(s) and/or block diagramblock(s).

The one or more computer-executable program code portions may also beloaded onto a computer and/or other programmable data processingapparatus to cause a series of operational steps to be performed on thecomputer and/or other programmable apparatus. In some embodiments, thisproduces a computer-implemented process such that the one or morecomputer-executable program code portions which execute on the computerand/or other programmable apparatus provide operational steps toimplement the steps specified in the flowchart(s) and/or the functionsspecified in the block diagram block(s). Alternatively,computer-implemented steps may be combined with operator and/orhuman-implemented steps in order to carry out an embodiment of thepresent invention.

While certain exemplary embodiments have been described and shown in theaccompanying drawings, it is to be understood that such embodiments aremerely illustrative of, and not restrictive on, the broad invention, andthat this invention not be limited to the specific constructions andarrangements shown and described, since various other changes,combinations, omissions, modifications and substitutions, in addition tothose set forth in the above paragraphs, are possible. Those skilled inthe art will appreciate that various adaptations and modifications ofthe just described embodiments can be configured without departing fromthe scope and spirit of the invention. Therefore, it is to be understoodthat, within the scope of the appended claims, the invention may bepracticed other than as specifically described herein.

What is claimed is:
 1. A data processing system for routing dataprocessing among different processing channels based on source-errorprobabilities, the data processing system comprising: a memory devicewith computer-readable program code stored thereon; a communicationdevice; a processing device operatively coupled to the memory device andthe communication device, wherein the processing device is configured toexecute the computer-readable program code to: receive a data processingjob comprising at least one data processing item; determine a firstsource of the at least one data processing item; determine a sourceerror probability associated with the first source; and based on thedetermined source error probability, route the data processing item fordata processing to an automated data processing network or a manual dataprocessing network.
 2. The data processing system of claim 1, whereinthe processing device is further configured to execute computer-readablecode to: determine a second source of information associated with thedata processing item; determine a source error probability associatedwith the second source; and based on the determined source errorprobabilities associated with both the first source and/or the secondsource, route or re-route the data processing item for data processing.3. The data processing system of claim 2, wherein the processing deviceis further configured to execute computer-readable code to: determine athird source of information associated with the data processing item;determine a source error probability associated with the third source;and based on the determined source error probabilities associated withthe first source, the second source and/or the third source, route orre-route the data processing item for data processing.
 4. The dataprocessing system of claim 2, wherein the processing device is furtherconfigured to execute computer-readable code to: route the dataprocessing item to an automated data processing network; and inresponse, determine the second source.
 5. The data processing system ofclaim 4, wherein the processing device is further configured to executecomputer-readable code to: based on the source error probability of thesecond source, re-route the data processing item to a manual dataprocessing network.
 6. The data processing system of claim 4, whereinthe processing device is further configured to execute computer-readablecode to: based on the source error probability of the second source,re-route the data processing item to a second automatic data processingnetwork determine a third source of the at least one data processingitem; determine a source error probability associated with the thirdsource; and based on the determined source error probabilitiesassociated with the third source, re-route or re-route the dataprocessing item to a manual data processing network.
 7. The dataprocessing system of claim 3, wherein the processing device is furtherconfigured to execute computer-readable code to: combine the sourceerror probabilities associated with each of the first source, secondsource and third source; compare the combined source error probabilitiesto a predetermined threshold; and in response, route the data processingitem.
 8. The data processing system of claim 3, wherein the secondsource of information comprises financial institution backendinformation and the third source of information comprises customerinformation.
 9. The data processing system of claim 1, wherein theprocessing device is further configured to execute computer-readablecode to: determine a type associated with the first source; based on thetype of the first source, determine a level of scrutiny for consideringdata processing items sourced from the first source; and based on thedetermined level of scrutiny, route the data processing item.
 10. Thedata processing system of claim 9, wherein the processing device isfurther configured to execute computer-readable code to: determine atleast one second source of information associated with the dataprocessing item; compare information from the first source with theinformation from the second source; and in response, adjust the level ofscrutiny lower if the information is the same and higher if theinformation is different.
 11. The data processing system of claim 9,wherein the at least one second source of information comprises afinancial institution backend system and/or a customer informationsystem.
 12. A computer program product for routing data processing amongdifferent processing channels based on source-error probabilities, thecomputer program product comprising at least one non-transitorycomputer-readable medium having computer-readable program code portionsembodied therein, the computer-readable program code portionscomprising: an executable portion configured for receiving a dataprocessing job comprising at least one data processing item; anexecutable portion configured for determining a first source of the atleast one data processing item; an executable portion configured fordetermining a source error probability associated with the first source;and based on the determined source error probability, an executableportion configured for routing the data processing item for dataprocessing to an automated data processing network or a manual dataprocessing network.
 13. The computer program product of claim 12,further comprising computer-readable program code to: determine a secondsource of information associated with the data processing item;determine a source error probability associated with the second source;and based on the determined source error probabilities associated withboth the first source and/or the second source, route or re-route thedata processing item for data processing.
 14. The computer programproduct of claim 13, further comprising computer-readable program codeto: determine a third source of information associated with the dataprocessing item; determine a source error probability associated withthe third source; and based on the determined source error probabilitiesassociated with the first source, the second source and/or the thirdsource, route or re-route the data processing item for data processing.15. The computer program product of claim 13, further comprisingcomputer-readable program code to: route the data processing item to anautomated data processing network; and in response, determine the secondsource.
 16. The computer program product of claim 15, further comprisingcomputer-readable program code to: based on the source error probabilityof the second source, re-route the data processing item to a manual dataprocessing network.
 17. The computer program product of claim 15,further comprising computer-readable program code to: based on thesource error probability of the second source, re-route the dataprocessing item to a second automatic data processing network determinea third source of the at least one data processing item; determine asource error probability associated with the third source; and based onthe determined source error probabilities associated with the thirdsource, re-route or re-route the data processing item to a manual dataprocessing network.
 18. The computer program product of claim 14,further comprising computer-readable program code to: combine the sourceerror probabilities associated with each of the first source, secondsource and third source; compare the combined source error probabilitiesto a predetermined threshold; and in response, route the data processingitem.
 19. The computer program product of claim 14, wherein the secondsource of information comprises financial institution backendinformation and the third source of information comprises customerinformation.
 20. A computer-implemented method for routing dataprocessing among different processing channels based on source-errorprobabilities, the method comprising: receiving, using a computingdevice processor, a data processing job comprising at least one dataprocessing item; determining, using a computing device processor, afirst source of the at least one data processing item; determining,using a computing device processor, a source error probabilityassociated with the first source; and based on the determined sourceerror probability, routing, using a computing device processor, the dataprocessing item for data processing to an automated data processingnetwork or a manual data processing network.